This invention relates generally to computer systems and more particularly to execution of computer programs on non-native computer system architectures.
As is known in the art, computer systems which generally include a central processing unit, a main memory, and input-output device interconnected by a system bus are used to execute computer programs to perform some useful task. One type of computer program is an operating system which is used to interface the central processing unit to an application program. The aforementioned application program is a program used by a user of the computer system to perform the useful task. The operating system includes all of the software resources needed by the computer system to interface each of the hardware elements to the computer system as well as to interface the application program and other programs on the computer system.
The application program which can include programs such as spreadsheets, wordprocessors, electronic mail executes on the computer system under the control of the operating system. In addition, the operating system often includes routines or libraries which the application program uses during execution.
It is generally known that application programs are written for a particular computer architecture that is, computer instruction set, as well as a particular operating system. Computer architectures are varied, but common architectures include the so-called Alpha(copyright) architecture by Digital Equipment Corporation""s assignee of the present invention, the so called X86 architecture which is based upon the family of microprocessors designed and built by Intel Corp., as well as others such as the Power PC(copyright) architecture designed and built by Motorola, IBM and Apple. Other architectures include the VAX(copyright) architecture by Digital Equipment Corporation and the PARISC(copyright) architecture by Hewlett Packard.
Generally, programs written for one architecture are also written for a particular operating system which is supported on the architecture. Thus, for the aforementioned Alpha architecture, the Alpha architecture supports the Windows NT(copyright) operating system by Microsoft Corporation, the Open VMS(copyright) operating system, by Digital Equipment Corporation, and the OSF-UNIX operating system by Digital Equipment Corporation.
These application programs written for one architecture and a particular operating system can not directly execute on a different architecture and/or different operating system. In general a so-called source file (which is a non-executable listing of the program) is fed to a compiler and linker to convert the source listings into executable code which a computer can execute.
New computer architectures are developed in order to provide significant performance improvements for the hardware associated with the architecture. For example, the so-called Alpha(copyright) architecture based upon the 64 bit Alpha microprocessor in a RISC type architecture (Reduced Instruction Set Computer). On such an architecture, an application program executes much faster with higher performance and thus provides to a user significant performance advantages.
One drawback to a new architecture, however, is that often application programs written for older architectures can not run directly on the new architecture. This occurs because the instruction acts of the new architecture and the old architecture are different and since different instructions are used in each architecture, the programs are not directly transferable.
While it is desirable for a user to migrate to a new higher performance architecture, one of the most significant drawbacks for a user to migrate to a new architecture is the user""s pre-existing investment in software applications as well as data files resulting from application programs on the old architecture. That is, an architecture which has been in existence for a number of years and used by a large number of users will represent a substantial cumulative financial investment. If that investment is not transferable to a new architecture users will be highly reluctant to migrate to the new architecture.
There are several approaches which have been developed over the years to assist users to migrate from an old architecture to a new architecture. One approach is the so-called xe2x80x9cporting approachxe2x80x9d. With the porting approach a software vendor agrees with the owner of the architecture to take its source code (i.e. the non-executable listing) for a particular application program and run the source code through a compiler developed for the new architecture and to perform some sort of checking such as a quality assurance check at the end of the compilation.
Thus, with porting the source code of application is converted into an executable image which can run on the new architecture. Porting is a viable solution for many applications. In particular applications involved in the so-called enterprise computing field are excellent candidates for porting since the nature of the program and the nature of the customer are such that there is an expectation of a high level of support from the software vendor as well as from the owner of the architecture.
However, porting is not always a viable option for certain segments of the computer market. In particular, in the so-called shrinkwrap software market porting is not a viable option. In the shrinkwrap market computer programs are bought relatively inexpensively and are used in personal computers. Often in this market there is not sufficient support for the user.
A further problem with porting is that a relatively large amount of time is required to port an application program to a new architecture, and it requires positive, active intervention of a human in order to port the application program. Further, the concept of porting assures the existence of availability of source code which is not always the case.
Another technique commonly employed is so-called xe2x80x9con-line interpretationxe2x80x9d. In on-line interpretation, a software module called an xe2x80x9cinterpreterxe2x80x9d interprets instructions from an executable version of the application program written in the non-native instruction set and chooses instructions or routines to execute in the new architecture. The interpreter is an emulator which responsive to a executable file corresponding to the old architecture provides a converted executable file that is executed on the new architecture.
The interpreter for each instruction tests the instruction to determine the resources needed by the instruction and analyzes the instruction to determine the function of the instruction. From this testing the interpreter maps the instruction to a routine that performs the same function only written in instructions executable on the new architecture. After the routine is identified the routine is executed in the computer system to provide the equivalent function called for in the application program written in the non-native instruction set. After execution a new instruction in the non-native architecture is provided to the interpreter.
Although interpreters are useful to convert application programs between architectures at run time, one of the significant drawbacks of interpreters is that they are exceedingly slow. Thus, performance advantages of the faster, high-performance architectures are lost with using an interpreter to convert instructions from an old architecture to a new architecture.
On-line translators have been used to alleviate this problem somewhat. In an on-line translator, small amounts of code that appears to the run-time system to be repetitive, is translated to improve the efficiency of the interpretation process. Generally a small buffer of the translated code is maintained and is used to execute until it is determined to translated code which has a higher usage rate. In that case the old translated code is overwritten. There are several problems with this approach. One problem is that there are very limited opportunities for optimization since the translation process can not hold up the interpretation process. A second problem is that translated code is saved only for short periods of time. Therefore repeated translations of the same code must be endured while the results of code are ultimately wasted.
A second technique commonly used is a so-called xe2x80x9cstate translatorxe2x80x9d. In a static translator, a software program called a translator receives an instruction sequence in the old architecture, and for each instruction sequence provides an instruction sequence in the new architecture to accomplish what the original instruction does in the old architecture. While a translator is generally faster than an interpreter, one problem with a translator is that often times non-native statements in the executable image are translated assuming that the statements were instructions when in fact the statements were not instructions but rather data or some other non-instruction information or heuristics.
This drawback may not cause problems in the execution of an application program in translated code since the translated non-instruction is never reached. Nevertheless, the use of this type of a translator increases the size of the memory file required to store the translated copy since it produces a translation of the entire file including non-code portions. Furthermore, the noncode translation minimizes the opportunities to run the translated code through an optimizer.
An optimizer is a compiler type of routine which operates on executable code to determine opportunities for reordering and otherwise, optimizing the executable code to provide improved performance. Optimizers are not generally useful with such online translators because the online translator invariably translates non-instruction code into instructions in the new architecture. Thus, any optimization which takes into consideration translated non instructions will most likely provide an optimized executable image which would have significant and fatal flaws.
Another problem with static translation is that it requires direct human intervention to invoke the translation process. While this may not be a concern for programs provided to the so-called enterprise market where there is a lot of system support for the user from the independent software vendor as well as the owner of the target architecture, this is a major concern for programs provided as so-called shrinkwrap where the user typically has little or no support.
In the shrinkwrap market, the typical user desires to load the application program and immediately begins execution of the program as desired without the need for intervention with a translation or interpretation process. Thus, the online interpreter and the static translator are not adequate solutions for converting programs from one architecture to another particularly for the so-called shrinkwrap market.
In accordance with the present invention is an apparatus for performing a binary translation of a first binary image to a second binary image. The apparatus includes a means for producing a first intermediate representation of the first binary image, a binary image converter, and a code generating means. The first intermediate representation includes one or more instruction codecells. A codecell includes an opcode corresponding to an instruction included in either a first or a second instruction set. The binary image converter includes a translator and an optimizer. The translator translates the first intermediate representation into a second intermediate representation in response to profile execution information. The optimizer intercommunicates with the translator to optimize the first intermediate representation. The code generating means generates the second binary image using the second intermediate representation.
With such an arrangement, a binary image is translated and optimized in a new and flexible way which efficiently uses computer system resources. The foregoing arrangement is flexible in that the steps of optimization and translation can be intermixed and performed in a variety of different orderings. The intermediate representation affords this flexibility by not imposing undue restrictions or making assumptions about the state of an intermediate representation at various points during translation and optimization.
Using the foregoing arrangement of the invention decreases development and maintenance costs associated with a binary translation process.